In today's data unit communication, an amount of data is divided into individual units, and said units are transmitted to a desired receiver over an appropriate communication path. This form of data communication is very well known and in wide use. The sending node may e.g. be a radio base station and the receiving node may be a user equipment such as a mobile phone, portable computer, Personal Digital Assistant (PDA) or vice versa. Most of these systems use bi-directional radio communication where both nodes transmit and receive data units simultaneously or alternating.
Such data units carry a variety of names in the context of different communication systems and communication protocols, such as packets, frames, segment, protocol data units, etc. The term “data unit” as used in the present specification and claims generically refers to any such division of a data amount.
In order to ensure the complete and correct transmission of data units from a transmitting to a receiving protocol peer, a mechanism referred to as ARQ (Automatic Repeat reQuest) is often used. ARQ mechanisms are commonly part of link layer protocols such as the Radio Link Control (RLC) protocol or the Medium Access Control (MAC) protocol specified for the Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN) as well as for the Evolved-UTRAN. When using an ARQ mechanism, the receiver of data units sends feedback messages to the sender, such that the sender can determine whether sent data units were properly received, and if not, to appropriately perform retransmissions of data units.
A feedback message is a control data unit that is typically sent from the receiving entity of an ARQ protocol to the transmitting peer entity.
Feedback messages are often referred to as status message, status report, status, etc. They may have different formats depending on the protocol specification. Known implementations of such status messages comprise one or more references to protocol data units, or parts thereof, received or expected by the receiving protocol entity. These references are typically denoted as positive and/or negative acknowledgements and also referred to as ACK or NACK. An acknowledgement provides the transmitting protocol entity with information about successful or unsuccessful reception of one or more data units at the receiving protocol entity. Many of the known ARQ protocols assign a so-called sequence number (SN) to each data unit and use this sequence number as reference in status messages. A positive acknowledgement for the data unit with a given sequence number may then be referred to as ACK_SN whereas a negative acknowledgement may be denoted as NACK_SN. Widely, known protocols use lists and/or bitmaps in status messages. An acknowledgement may be explicit, i.e., represent the state of one particular data unit or it may be cumulative, i.e., provide information about the state of a collection of data units.
The radio link control protocol specified for E-UTRAN uses combinations of the two. In said protocol the positive acknowledgement is cumulative, i.e., it positively acknowledges all data units with a sequence number up to but not including ACK_SN that are not explicitly negatively acknowledged. In the status messages of said protocol a negative acknowledgement is transmitted by means of a NACK_SN field for each not received data unit below ACK_SN.
Data units and control data units such as status messages may comprise a payload section and a header section where the former contains the actual information to be exchanged between the peer protocol entities and the latter carries information needed to decode that information correctly. The header section of a data unit may for example comprise the associated sequence number.
One example of a status message is the LTE RLC STATUS PDU in E-UTRAN disclosed in FIG. 1. In the example of FIG. 1, each row comprises eight bits, i.e. one octet (Oct 1, Oct 2, etc.). The data unit comprises a payload section and a header section. The header section comprises a Data/Control (D/C) and a Control PDU Type (CPT) field. The D/C field indicates whether the data unit is an RLC data PDU carrying payload from higher layers or an RLC control PDU, namely a status message. The CPT field indicates the type of the RLC control PDU. The payload section following the header section comprises an ACK_SN field and an extension flag E1. The former carries the sequence number following that of the highest received data unit and it cumulatively acknowledges all data units up to but not including that sequence number which are not negatively acknowledged in the remainder of the status message. The E1 flag indicates whether or not a set of NACK_SN, E1 and E2 follows. The NACK_SN field comprises the sequence number of a data unit which has been detected as missing by the receiving protocol entity, i.e., a negative acknowledgement. The E2 field indicates whether or not a set of SOstart and SOend follows. The SOstart field together with the SOend field indicates the portion of the data unit with SN=NACK_SN (the NACK_SN which the SOstart is related to) that has been detected as lost at the receiving protocol entity. In this example the ACK_SN field as well as all NACK_SN fields comprise 10 bit and can therefore address 210=1024 sequence numbers. In order to be able to transmit more data units, a wrap-around mechanism may be used so that the sequence number space can be re-used.
In accordance with the generic description of ARQ mechanisms the transmitting side of an LTE RLC Acknowledged Mode (AM) RLC entity interprets a received STATUS PDU so that all Acknowledge Mode Data (AMD) PDUs up to but excluding the AMD PDU with SN=ACK_SN have been received by its peer AM RLC entity, excluding those AMD PDUs indicated in the STATUS PDU with NACK_SN and also excluding portions of AMD PDUs indicated in the STATUS PDU with NACK_SN, SOstart and SOend.
In general and also in the particular example of LTE RLC the status messages provide the complete status information to the ARQ sender, i.e., the status message comprises information about the entire receive window. Therefore, the size of the status message increases with the number of negative acknowledgement to be reported by the receiving protocol entity. Due to varying radio channel quality or inappropriate resource assignments the available radio resources may not be sufficient to transmit an entire status message.
Examples of solutions to the problem that the available resources are too small to send a full status message are to either prioritize status messages to ensure that enough resources are available which implies that other transmissions are delayed, or to postpone the transmission of a status message until sufficient resources are available which would lead to window stalling or increased transmission delays which are also unfavourable. These solutions are likely to lead to situations where the receiver may not be allowed to send any status message due to insufficient radio resources.